home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19970929-19971216 / 000107_news@newsmaster….columbia.edu _Wed Oct 15 18:24:04 1997.msg < prev    next >
Internet Message Format  |  1997-12-15  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id SAA23212
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 15 Oct 1997 18:24:03 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id SAA27825
  7.     for kermit.misc@watsun; Wed, 15 Oct 1997 18:24:02 -0400 (EDT)
  8. Path: news.columbia.edu!panix!howland.erols.net!news.maxwell.syr.edu!scanner.worldgate.com!rover.ucs.ualberta.ca!alberta!not-for-mail
  9. From: Vladimir Alexiev <vladimir@cs.ualberta.ca>
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit via PPP under DOS? (SOLVED!)
  12. Date: 15 Oct 1997 16:06:41 -0600
  13. Organization: University of Alberta, Computing Science
  14. Lines: 63
  15. Message-ID: <omen5m8yvj.fsf@tees.cs.ualberta.ca>
  16. References: <k1c7kBQEU5Wv@cc.usu.edu> <omvhza9x7g.fsf@tees.cs.ualberta.ca>
  17.     <5jzp7SiZjuUm@cc.usu.edu> <omn2kcqegc.fsf@tees.cs.ualberta.ca>
  18. NNTP-Posting-Host: tees.cs.ualberta.ca
  19. In-reply-to: Vladimir Alexiev's message of 14 Oct 1997 14:25:55 -0600
  20. to: jrd@cc.usu.edu (Joe Doupnik)
  21. X-Newsreader: Gnus v5.0.15
  22. Xref: news.columbia.edu comp.protocols.kermit.misc:7886
  23.  
  24. Alright! 
  25.  
  26. Joe, you were right on these points:
  27. - It's EPPPD's fault, not Kermit's fault
  28. - I should have talked earlier to EPPPD's author
  29. I was right on these points:
  30. - It's easy to fix.
  31. - Other apps work because they don't check something that should be checked.
  32.   Kermit fails because it's right, but "too righteous". Worse is better :-)
  33.  
  34. Something that threw me off is that MeritPPP also failed. Two drivers against
  35. one kermit, it's "natural" to assume it's kermit's fault :-) I wonder if
  36. MeritPPP has the same bug as EPPPD, and if we can get someone at Merit to fix
  37. it. 
  38.  
  39. I'll give it a try and inform you. 
  40. Regards, Vlad
  41.  
  42.  
  43. Date:    Wed, 15 Oct 1997 23:41:36 +0100 (GMT+0100)
  44. From:    Toni <tonilop@redestb.es>
  45. Subject: Re: Class 1 PPP drivers under DOS vs true Ethernet
  46.  
  47. Hello Vladimir,
  48.  
  49. I already knew of the Dospppd + Kermit problem, as some users reported the
  50. failure to me some time ago. The problem is corrected now, there is a pre-beta
  51. of Dospppd v0.6 package at the following URL:
  52.  
  53. http://www.redestb.es/personal/tonilop/dosppp06.zip
  54.  
  55. Please don't redistribute this package, as it is incomplete and subject to
  56. changes before I release the publicly available one. However, I'm interested in
  57. knowing how well it performs, or if it has bugs, so let me know how it goes in
  58. case you have the time for testing it. You may want to inform Joe Dupnik also.
  59.  
  60. A summary of what I've discovered and the solution follows:
  61.  
  62. Real Ethernet ARP reply packets include the source address (the address for the
  63. machine which is responding to the ARP request) in two places, one is in the
  64. Ethernet header source address field, and the other is in the ARP packet source
  65. hardware address field.
  66.  
  67. It seems that most applications look at the source hardware field of the ARP
  68. packet, so the ARP emulation in Dospppd was filling only this one with the fake
  69. Ethernet address.
  70.  
  71. On the other hand, Kermit seems to look at the Ethernet header source address
  72. field, or maybe it is doing a consistency check by ensuring that both fields
  73. contain the same value (I don't know for sure, maybe Mr. Dupnik would give some
  74. insight on this issue).
  75.  
  76. The solution was to put the same fake Ethernet address in both fields, Kermit
  77. started to work fine after that. It is not a Kermit problem though, an Ethernet
  78. emulation should fill both fields in order to be acurate. The fact that most
  79. other WATTCP applications worked doesn't imply that Kermit was wrong, maybe
  80. WATTCP developers decided to relax the Ethernet address checks after detecting
  81. that the stack didn't work with Ethernet emulation drivers.
  82.  
  83. Best regards.
  84.  
  85. Toni
  86.